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1.  Introduction 
1.1  Purpose 

This  paper  specifies  the  Modeling  and  Simulation  Data  Engineering  Technical  Framework 
(M&S  DE-TF).  Within  the  Modeling  and  Simulation  Common  Technical  Framework  [1], 
the  M&S  DE-TF  is: 

•  the  formal  vehicle  for  promulgating  and  enforcing  data  standards,  and 

•  a  template  for  using  data  standards  to  create,  manage,  and  deliver  data  . 

In  particular,  the  DE-TF  (Figure  1)  provides  data: 

•  recognition  through  common  semantics  and  syntax, 

•  realization  through  data  systems  architecture, 

•  repeatahility  through  a  closed-loop  engineering  process 

•  reuse  through  standard  data  products,  and 

•  standards  through  M&S  functional  data  administration  . 

1.2.  Applicability 

The  M&S  Data  Engineering  Technical  Framework  version  0.2  applies  to  all  DMSO  sponsored 
organizations,  products,  and  activities  within  the  scope  of  the  DoD  Directive  5000.59  Modeling  and 
Simulation  Master  Plan  [1]. 

1.3.  Organization 

This  specification  of  the  M&S  Data  Engineering  Technical  Framework  is  organized  as  follows. 
Section  1  introduces  the  DE-TF.  Section  2  provides  an  overview  of  the  fundamental  concepts  and 
components  of  the  framework.  Section  3  provide  a  detailed  expositions  of  the  DE-TF  products  and 
processes.  Fengthy  expositions  or  extended  examples  are  provides  as  enclosures.  References,  figures,  and 
tables  are  collected  in  to  Sections  4,  5,  and  6,  respectively.  Section  7  provides  a  DE-TF  specifications 
compendium.  Where  appropriate,  technical  derivations  or  detailed  trade-studies  are  referenced  as  external 
documents.  Specific  data  standards  which  provide  formal  Interface  Design  Descriptions  (IDD)  are 
referenced  as  external  annexes  to  this  document. 

1.4.  Objectives 

The  traditional  DoD  M&S  product  development  and  delivery  paradigm  enforces  a  rigorous,  top-down 
procedure  where: 

•  requirements  are  derived  from  specific  operational  needs, 

•  designs  are  derived  from  requirements,  and 

•  custom  components  are  created  to  implement  the  design. 
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While  producing  individually  excellent  products,  this  exclusively  top-down  procedure  leads  to  stove-piped 
M&S  solutions  with  these  undesirable  side-effects: 

•  limited  interoperability  and  re-use  between  independently  conceived  products, 

•  reduced  credibility  of  results  when  the  stove-pipe  does  not  include  key  communities,  and 

•  response  to  changing  requirements  can  be  costly  in  time,  resources,  and  quality. 

A  fundamental  objective  of  DoD  Directive  5000.59  is  to  address  these  undesirable  side-effects  by 
developing  the  infrastructure  required  for  composable  solutions.  Composable  solutions  employ  the 
principle  of  design  inversion  where: 

•  requirements  are  derived  from  specific  operational  needs, 

•  families  of  standard  plug-and-play  components  are  retained  in  a  repository,  and 

•  specific  designs  are  created  to  meet  the  requirements  using  existing  components  from  the  repository. 

In  particular,  the  DoD  M&S  Master  Plan  [1]  has  directed  the  development  of  an  M&S  Common  Technical 
Framework  (Objective  1),  authoritative  representations  of  the  environment,  units  and  systems,  and  human 
behavior  (Objectives  2-4),  and  infrastructure  (Objective  5)required  to  enable  composable  solutions. 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  is  leading  the  effort  to  develop  the  required 
M&S  Common  Technical  Framework  (M&S  CTF).  The  M&S  CTF  has  three  principal  components: 

•  High  Level  Architecture  (HLA) 

•  Conceptual  Models  of  the  Mission  Space  (CMMS),  and 

•  Data  Standards 

as  directed  in  DoD  Directive  5000.59.  Within  the  M&S  Common  Technical  Framework  and  the  associated 
authoritative  representation  objectives,  the  Data  Engineering  Technical  Framework  is 

•  the  formal  vehicle  for  promulgating  and  enforcing  data  standards,  and 

•  a  template  for  using  data  standards  to  create,  manage,  deliver,  and  employ  data  . 

M&S  activities  will  employ  the  DE-TF  to  provide  composable  data  solutions  which  are: 

•  derived  from  authoritative  sources, 

•  described  using  common  semantics  and  syntax 

•  interchanged  using  standard  formats, 

•  subject  to  rigorous  quality  checks, 

•  released  to  authorized  consumers  and, 

•  protected  from  unauthorized  access  or  modification. 

In  particular,  the  data  standards  incorporated  into  the  DE-TF  (Figure  1)  will  provide 

•  Recognition  of  stmcture  and  content  through  common  semantics  and  syntax,  including: 

•  standard  naming  conventions  in  a  common  lexicon. 
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•  entity-based  and  action-based  data  element  dictionaries, 

•  common  taxonomies  within  identified  application  clusters, 

•  layered  architecture  which  separates  implementation  and  problem  domain  semantics, 

•  integration  with  existing  standards  from  other  (non-M&S)  functional  areas, 

•  capture,  matching,  and  mapping  procedures  and  utilities, 

•  Realization  of  instance  values  within  a  data  systems  architecture,  including 

•  the  Modeling  and  Simulation  Resource  Repository  (MSRR)  [1,2] 
for  consistent  physical  access  and  network  connectivity, 

•  families  of  interfaces  (low-level  formats,  intermediate-level  API,  high-level  GUI,  etc.),  and 

•  hardware/software  platform  standards  and  constraints. 

•  Repeatability  through  data  development  processes  which  provide 

•  a  standard  Data  Production  Sequence,  and 

•  a  closed-loop  Data  Engineering  Process. 

•  Reuse  through  data  products,  specifically: 

•  development  and  designation  of  Authoritative  Data  Sources, 

•  information  exchange  using  Data  Interchange  Formats, 

•  specification  and  employment  of  Data  Quality  (DQ)  practices  and 

•  specification  and  enforcement  of  Data  Security  (DS)  practices. 

•  Standards  through  DoD  M&S  Functional  Data  Administration  (M&S  FDAd). 

DMSO  is  developing  the  DE-TF  in  conjunction  with  the  JSIMS  and  JWARS  M&S  development 
programs,  the  Defense  Information  Systems  Agency  (DISA)  with  their  associated  Component  and 
Functional  Data  Administrators,  and  the  OSD  PA&E  Joint  Data  System.  DMSO  anticipates  that  a  number 
of  other  Service  and  Component  data  programs  will  also  make  significant  contributions  to  the  DE-TF 
including:  the  Defense  Intelligence  Agency  MIDB  and  MEPED,  the  Naval  Warfare  Tactical  Database 
(NWTDB),  and  the  Air  Force  MASTR  database. 


1.5.  Specifications 

DE-TF  specifications  are  captioned: 


•  Minimum  Requirement:  mandatory  specification  considered  necessary  (but  not  necessarily 

sufficient)  for  data  interoperability  and  re-use. 

•  Preferred  Practice:  best  practices  specification  considered  sufficient  for  data 

interoperability  and  re-use. 


•  Technology  Extension:  optional  specification  which  in  not  considered  mandatory  for 

data  interoperability  and  re-use  but  which  is  considered 
indicative  of  the  technology  adoption  trend. 
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2.  Fundamental  Concepts 

The  DE-TF  specification  provided  here  will  employ  reserved  words,  first  to  define  basic  terms  and 
concepts  and  then  construct  more  general  and  complex  terms  and  concepts  from  the  basics: 

RESERVED  WORD 

A  specific  term  or  concept  which  is  defined  and  used  to  specify  the  Data  Engineering  Technical 
Framework.  These  terms  will  be  typed  in  bold  small  caps. 

Following  the  DoD  M&S  Master  Plan  [1],  the  definitions  provided  in  the  Glossary  of  M&S  Terms  [3],  and 
the  DoD  Data  Dictionary  System  (DDDS)  [4]  are  included  here  as  RESERVED  WORDS  by  reference.  Changes  or 
extensions  to  these  external  definitions  in  this  Data  Engineering  Technical  Framework  are  italicized  in  the 
body  of  the  definition. 

2.1  Basic  Definitions 

This  section  develops  the  inter-related  concepts  of:  data,  model,  information,  representation, 
simulation,  and  resource  in  the  context  of  modeling  and  simulation  requirements.  These  terms  are  then 
employed  to  define  fundamental  data  engineering  concepts. 

DATA 

Specification  of  facts,  parameters,  values,  concepts,  or  instructions  in  a  formalized  manner 
suitable  for  communications,  interpretation,  or  processing  by  humans  or  by  automatic  means. 
This  definition  of  data  is  a  compatible  modification^  of  the  definitions  in  [3-4]. 

“Messages  which  resolve  ambiguity  are  information.  All  other  messages  are  noise.”  [5].  Therefore: 

INFORMATION 

DATA  in  context  related  to  a  specific  purpose  [6] . 

MODEL 

A  physical,  mathematical,  or  otherwise  logical  specification  of  a  system,  entity,  phenomenon,  or 
process.  This  definition  of  model  is  a  compatible  modification  of  the  definitions  in  [3]. 

REPRESENTATION 

The  combination  of  a  model,  process,  or  algorithm  and  the  associated  data,  parameters,  or  values. 
Traditional  implementations  sharply  separate  algorithms  and  values.  Contemporary  object- 
oriented  implementations  joins  model  and  data  as  an  object. 

SIMULATION 

The  implementation  of  a  representation  over  time.  This  definition  is  a  compatible  modification  of 
the  definition  in  [3] 

Resource 

The  entities  and  expendable  which  may  be  used  by  a  process.  Resources  include  models,  data, 
REPRESENTATIONS,  SIMULATIONS,  facilitics,  cquipmeut,  systems,  software,  source  code,  manpower, 
computer  time,  calendar  time,  funding,  etc. 

DATA  is  a  critical  enabling  factor  in  the  composable  solutions  strategy  both  as  an  end  in  itself  and  as  a 
means  to  an  end.  As  an  example,  consider  the  HLA  Federation  Development  and  Execution  Process 


*  Replaced  “representation”  in  [4-5]  with  “specification”  to  avoid  circular  definition  of  representation. 
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(FEDEP)  depicted  in  Eigure  2.  The  traditional  focus  of  M&S  data  standards  has  been  the  start-exercise 
scenario  instance  data  shown  in  the  PRODUCTS  block  of  Eigure  2.  This  is  data  as  an  end  in  itself.  Note 
that  the  every  arrow  on  the  diagram  represents  data  interchange.  Moreover,  over  one-half  of  the  blocks  on 
the  diagram  constitute  resources  which  can  converted  to/from  data  for  archive  and  interchange.  Even  within 
the  TEST  and  EXECUTION  blocks,  the  composable  solutions  strategy  distributes  simulation  functionality 
among  the  federates  using  HLA-compliant  data  interchange.  This  is  data  as  a  means  to  an  end.  The  Data 
Engineering  Technical  Eramework  provides  the  development  process,  interoperability  standards,  and 
integration  procedures  required  for  data  within  the  composable  solutions  strategy. 

2.2  Representation 

The  cornerstone  of  the  M&S  Data  Engineering  Technical  Eramework  is  this:  composable  data 
solutions  are  feasible  precisely  when  the  associated  representation  is  explicit.  This  is  the  essence  of 
recognition  and  the  jump  off  point  for  realization,  extension  to  repeatability,  and  eventual  reuse.  In  most 
circumstances,  the  choice  of  representation  is  a  matter  of  focus.  Two  important  components  of  this  choice 
are 


•  the  real  world  focus  of  the  military  activities  of  interest  (the  problem  domain)  and 

•  the  synthetic  world  focus  of  the  simulation  application  (the  implementation  domain). 

2.2.1  Real  World  Focus 

ABSTRACTION 

A  mental  facility  that  permits  humans  to  view  real  world  problems  with  varying  degrees  of  detail 
depending  on  the  current  context  of  the  problem  [7] .  abstraction  is  the  real  world  equivalent  of 
the  synthetic  world  representation  used  in  simulation. 

Real  world  military  activities  have  a  focus.  While  all  physical  and  cognitive  details  of  the  real  entities 
and  their  actual  behaviors  are  present  with  perfect  fidelity,  not  all  details  are  important  or  are  readily 
discernible  in  the  focus  of  the  real  military  operation.  Eor  example,  consider  an  E/A- 18  allocated  to  a  deep 
penetration  air  interdiction  mission.  In  the  actual  military  operations,  the  details  which  are  include  or 
excluded,  the  granularity  and  aggregation  of  information  provided  to  the  real  warfighter  is  very  different  if 
that  warfighter  is 

•  a  general  officer  in  the  Unified  Command, 

•  the  wing  commander  in  the  JEACC  air  operations  center, 

•  the  flight  leader  in  the  strike  package,  or 

•  the  pilot  of  the  E/ A- 18. 

That  is,  the  real  world  executes  real  operations  by  introducing  distinct  ABSTRACTIONS  which  correspond  exactly 
to  the  real  world  decomposition  of  tasks  and  allocation  of  resources.  Note  this  introduction  of  abstraction  is 
part  to  the  problems  space  —  not  the  implementation  domain. 
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This  use  of  aBSTRACTioN  is  an  intrinsically  human  activity  to  reduce  the  full  complexity  of  the  real  world 
to  manageable  proportions  hy  filtering  out  unnecessary  details  [13].  Entities,  actions,  characteristics,  and 
behaviors  near  the  real  world  focus  are  abstracted  to  the  real  world  actors  with 

•  fine-grained  decomposition’s, 

•  extensive  detail,  and 

•  higher  fidelity. 

Entities  and  actions  distant  from  the  real  world  focus  are  ABSTRACTED  with 

•  coarse-grained  decomposition’s, 

•  limited  detail,  and 

•  lower  fidelity. 

The  objective  of  these  ABSTRACTIONS  employed  in  real  activities  is  to  provide  data  in  context,  i.e. 

INFORMATION,  to  support  dccistons  by  rejecting  noise.  In  real  world  or  problem  domain,  the  data  is  almost 
always  explicitly  provided  as  INFORMATION  ;  whereas,  the  underlying  MODEL  which  completes  the  ABSTRACTION 
usually  is  implicit.  Under  the  M&S  Common  Technical  Eramework,  this  understanding  of  the  real  world  is 
captured  and  maintained  as  Conceptual  Models  of  the  Mission  Space  (CMMS)  [8]. 

Minimum  Requirement: 

DATA  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Eramework  shall  be  traceable  to  an  appropriate  REPRESENTATION  of  the 
corresponding  problem  domain  ABSTRACTION  registered  in  CMMS. 

2.2.2  Simulation  Focus 

Just  as  real  operations  have  a  focus,  every  simulation  has  a  focus.  The  simulation  focus  is  derived 
from  the  real  world  focus  and  the  simulation  objectives  as  follows: 

•  Obtain  representations  of  the  real  world  focus  of  the  entities,  actions,  tasks, 
and  interactions  of  interest  from  CMMS. 

•  Extend  the  scope  and  context  of  the  real  world  focus  to  include  notional  entities/actions, 
hypothetical  situations,  and  to-be  conditions  —  again  in  the  form  of  CMMS  REPRESENTATIONS . 

The  simulation  objectives  are  then  imposed  as  constraints  on  the  extended  real  world  focus  to  complete  the 
simulation  focus.  These  constraints  imposed  by  the  simulations  are  often  called  the  Conceptual  Model  of 
the  User  Space  (CMUS)  [9].  Typical  constraints  on  the  simulation  focus  include: 

•  the  range  of  anticipated  Essential  Elements  of  Analysis  (EEA’s)  or 
Measures  of  Effectiveness  (MOE’s)  in  analysis  applications, 

•  the  training  audience  and  readiness  objectives  (e.g.  the  WarSim 
Task  Requirements  Analysis  Process  or  TRAP), 

•  real-time,  faster  than  real-time,  or  as  fast  as  possible  computational  requirements,  or  perhaps 

•  the  anticipated  hardware/software  platforms  with  associate  processing  limits. 
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Just  as  in  the  real  world  focus,  synthetic  entities,  actions,  characteristics,  and  behaviors  near  the  simulation 

focus  are  REPRESENTED  with 

•  fine-grained  decomposition’s, 

•  extensive  detail,  and 

•  higher  fidelity. 

And  synthetic  entities  and  actions  distant  from  the  simulation  focus  are  REPRESENTED  with 

•  coarse-grained  decomposition’s, 

•  limited  detail,  and 

•  lower  fidelity. 

The  correlation  between  the  real  world  focus,  the  simulation  focus,  and  the  specific  REPRESENTATION 
chosen  is  critical.  For  an  identified  simulation  focus,  data  is  created  to  complete  the  synthetic  REPRESENTATIONS 
of  these  real  world  entities  and  actions  for  use  in  a  simulation.  Note  that  representations  are  plural  here.  For 
any  specific  entity  or  action,  there  is  usually 

•  more  than  one  REPRESENTATION 
or  within  a  particular  REPRESENTATION 

•  more  than  one  MODEL  and/or 

•  more  than  one  set  of  DATA  elements 

that  provide  an  appropriate  description  of  that  entity  or  action  depending  upon  the  real  world  context  and 
the  simulation  focus.  That  is,  for  any  specific  entity  or  action,  there  are  families  of  distinct  but  related 

REPRESENTATIONS,  MODELS,  and/or  data.  Whether  a  verified  and  validated  representation  is  information  or  noise  depends 

upon  the  end-use. 

Minimum  Requirement: 

DATA  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Framework  shall  be  traceable  to  an  appropriate  REPRESENTATION  of  the 
implementation  domain  ABSTRACTION  registered  in  a  CMUS. 

2.3  Primary  Components 

There  are  five  primary  components  of  the  M&S  Data  Engineering  Technical  Eramework: 

•  Common  Semantics  and  Syntax 

•  Data  Systems  Architecture 

•  Data  Processes 

•  Data  Products 

•  M&S  Eunctional  Data  Administration 
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2.3.1  Common  Semantics  and  Syntax 

A  fundamental  objective  of  data  standards  is  to  provide  simulation  developers  and  end-users  with 
timely  and  cost-effective  access  to  accurate  data  which  are  created,  authenticated,  and  maintained  by  others. 
DATA  recognition  is  the  first  requirement.  No  data  set,  however  valuable,  will  be  consider  from  inclusion  in  a 
composable  solution  if  that  data’s  suitability/appropriateness  for  the  solution  is  not  recognizable  to  the 
simulation  developer  or  end-user.  In  many  cases,  the  official  language  used  by  subject  matter  experts  in 
distinct  warfare  or  the  well  established  nomenclature  in  a  specific  technologies  is  a  barrier  to  this  direct  use 
and  re-use  of  data.  While  correct  and  legitimate  within  its  own  domain,  the  official  semantics  and  syntax  in 
one  warfare  area  or  technical  discipline  often  is  in  direct  conflict  with  the  formal  language  in  another 
domain.  Even  at  a  basic  vocabulary  level,  there  are  cases  where  identical  words  are  used  to  mean  very 
different  things,  and  there  are  cases  where  different  words  are  used  to  mean  the  same  thing.  To  make 
effective  use  of  Data  Standards,  simulation  developers  require  REPRESENTATIONS  and  their  associated  MODELS  and 
DATA  that  map  domain  specific  descriptions  to  a  common  semantics  and  syntax. 

SYNTAX 

The  symbols  and  structures  which  may  be  used  in  a  representation  and  the  ways  that  those  symbols 
may  be  arranged  within  the  allowed  structures. 


SEMANTICS 

The  content  or  meaning  embodied  in  the  symbols  and  symbol  arrangements  defined  in  a  syntax. 


COMMON  SEMANTICS  AND  SYNTAX 


An  implementation-independent  logical  specification  of  representation  structure  and  content 
within  a  specified  scope  and  context. 


FORMAT 

a  set  of  semantic  and  syntactic  conventions  that  define  the  physical  implementation  of  data. 

The  central  objective  of  common  semantics  and  syntax  is  resource  recognition.  For  data  resources,  CSS  is 
usually  defined  as  an  IDEFIX  logical  data  model  [10-12]  with  associated  data  element  dictionary.  Within 
the  composable  solutions  strategy,  CSS  provides 

•  standard  naming  conventions  in  a  common  lexicon, 

•  entity-based  and  action-based  data  element  dictionaries, 

•  common  taxonomies  within  identified  application  clusters, 

•  layered  architecture  which  separates  implementation  and  problem  domain  semantics, 

•  integration  with  existing  standards  from  other  (non-M&S)  functional  areas,  and 

•  capture,  matching,  and  mapping  procedures  and  utilities, 

which  enable  simulation  developers  and  end-users  to  readily  recognize  existing  components  as  candidates 
for  implementing  their  requirements. 

TheF/A-18  REPRESENTATION  example  cited  in  Section  2.2  is  a  special  case  of  a  more  general  observation 

[13]  that  ABSTRACTION 

•  in  the  form  of  a  hierarchical  chain  of  command  and  control  is  central  to  the  planning  and 
execution  of  military  operations,  and 
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•  in  the  form  of  a  hierarchical  chain  of  components  and  networks  is  central  to  the  processing 
characteristics  and  performance  of  military  systems. 

That  is,  real  organizations  and  systems  employ  layered  architectures  to  accommodate  and  implement  the 
required  hierarchies  of  abstraction.  Therefore,  CSS  recognizes  distinct  hut  related  families  of  REPRESENTATIONS 
in  a  layered  architecture  which  explicitly  mimics  the  real  world  usage  of  hierarchical  ABSTRACTION. 

Recall  that  the  primary  purpose  of  common  semantics  and  syntax  is  provide  data  recognition  hy  making  the 
REPRESENTATION  explicit.  Therefore  the  first  step  in  developing  CSS  is  to  identify  the  key  organizing  principles 
(or  primary  dimensions)  which  describe  the  military  activities  of  interest.  As  an  example,  consider  the 
JWARS  and  JSIMS  mission  space.  As  illustrated  in  Figure  3,  there  are  (at  least)  three  primary  organizing 
principles  or  dimensions: 

•  level  of  war, 

•  phase  of  campaign,  and 

•  allegiance  of  forces 

required  to  describe  the  JWARS  and  JSIMS  mission  space.  While  there  certainly  are  more  organizing 
principles  within  the  JWARS/JSIMS  domain  (from  example,  analysis  versus  training),  the  number  of 
primary  dimension  which  can  be  accommodated  is  finite  and  usually  less  than  seven  [14].  Within  any 
specific  cell  in  Figure  3,  CSS  provides  standards  terms  of  reference,  naming  conventions,  structures,  and 
taxonomies  based  on  the  focus  —  both  real  world  and  simulation  related  -  of  the  activities  and  entities  in 
that  cell.  Between  cells  mapping  and  matching  interfaces  will  be  required  -  either  because  the 
representations  of  the  same  real  world  entity/action  are  distinct  or  because  the  naming  and 
nomenclature  are  distinct. 

The  organizing  principles  defined  in  Table  1  are  of  particular  importance  within  the  M&S  Data 
Engineering  Technical  Framework.  The  Universal  Joint  Task  List  (UJTL)  [15]  defines  military  operations 
in  terms  of  the  four  hierarchical  layers  (or  levels  of  war)  shown  in  the  left  most  column  of  Table  1  as 
follows: 


The  level  at  which  national  command  authorities  and  combined  operational  commands 
determine  the  security  objectives  and  warfare  guidance  with  associated  allocation  of  resources. 
With  these  objectives,  guidance’s,  and  resources,  strategic  level  activities  establish  missions, 
national  and  multi-national  objectives,  sequence  initiatives,  define  limits  ,  and  assess  risks  for  the 
use  of  military  and  other  instruments  of  national  power.  At  the  strategic  level,  the  activities  lead 
to  the  development  of  global  and  theater  war  plans  and  the  provision  of  military  forces  and 
capabilities. 


The  level  at  which  combined  operational  commands,  joint  and  Service  specific  task  forces  plan, 
conduct,  and  sustain  strategic  level  objectives  within  geo-spatial  theaters  of  activity.  These 
activities  link  the  strategic  level  and  the  tactical  level  by  establishing  objectives,  sequencing 
events  initiating  actions,  and  applying  resources  at  the  appropriate  operational  level. 
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TACTICAL  LEVEL 

The  level  at  which  joint  and  Service  specific  task  forces,  individual  military  units,  and  multi-role 
platforms  plan  and  execute  the  ordered  arrangement  and  maneuver  of  combat  elements  in  space 
and  time  relative  to  own  and  adversary  forces  to  achieve  combat  objectives. 

The  STRATEGIC  LEVEL  Is  usuolly  sub-divided  into  S  TRATEGI C —NAT  ZONAL  and  STRATEGIC— THEATER  levels  as  shown  in  the 

table.  Within  each  UJTL  level  of  war,  the  items  to  be  represented  are  organized  according  to: 

TASK  REPRESENTATION 

The  REPRESENTATION  of  actious  to  be  executed  and  processes  to  be  performed  within  a  mission. 


PHYSICAL  REPRESENTATION 


The  REPRESENTATION  of  engineering,  physics,  chemistry,  biology,  or  psychology  principles  to  determine 
material  characteristics  and  performance  or  to  establish  human  cognitive  and  psychological  factors. 


WARFIGHTER  REPRESENTATION 

The  REPRESENTATION  of  iudividual  persons  employing  physical  resources  (platforms,  systems,  sensors, 
munitions,  communications,  etc.)  to  execute  a  task. 

The  DoD  Instruction  5000.59  defines  these  types  of  simulations: 

LIVE  SIMULATION 

Real  WARFIGHTERS  Interacting  with  real  systems  in  a  real  environment 


VIRTUAL  SIMULATION 

Real  WARFIGHTERS  interacting  with  synthetic  systems  in  a  synthetic  environment 


CONSTRUCTIVE  SIMULATION 

Synthetic  warfighters  interacting  with  synthetic  systems  in  a  synthetic  environment 

Cells  in  the  same  row  of  Table  1  share  common  actions  and  entities  at  the  same  level  of  warfare. 
Mapping  and  matching  is  required  to  substitute  synthetic  representation  for  real  items  when  moving 
horizontally  from  real  operations  on  the  left  to  completely  synthetic  operations  on  the  right.  Cells  in  the 
same  column  share  the  same  mixture  of  real  and  synthetic.  Aggregation/de-aggregation  interfaces  are 
required  to  move  vertically  between  levels  of  war. 

Organization  of  REPRESENTATIONS  according  to 

•  UJTL  level  of  warfare, 

•  degree  of  synthetic  REPRESENTATION,  and 

•  the  relative  focus  among  action,  entity,  or  actor 

are  the  foundation  of  COMMON  SEMANTICS  AND  SYNTAX  within  the  M&S  Data  Engineering  Technical  Framework. 
Therefore: 

Minimum  Requirement:  data  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Framework  shall  be  described  using  COMMON  SEMANTICS  AND  SYNTAX,  including  but  not  limited  to: 

A  taxonomy  which  identifies  the  key  organizing  principles  and  primary  describing 
dimensions  of  the  REPRESENTATION  which  the  data  completes.  This  taxonomy  shall  include  but  is 
not  limited  to  the  organizing  principles  defined  in  Table  1. 
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DATA  element  dictionary  which  complies  with  the  DoD  Data  Dictionary  System  [4]  structure 
and  content  specifications. 

A  DATA  model  which  defines  the  relationships  between  the  elements  in  the  data  dictionary 
within  the  taxonomy  provided  and  which  complies  with  the  DoD  Data  Model  [16] 
structure  and  content  specifics. 

Preferred  Practice: 

The  required  CSS  data  model  and  associated  data  elements  should  he  constructed  in 
accordance  with  DoD  5000.59-M-l  [17]. 

Technology  Extension: 

Employ  the  Data  Analysis  and  Reconciliation  Tool  (DART)  [18]  to  define  entity-hased  data 
elements. 

Employ  the  CMMS  Verb  Dictionary  [19]  to  define  action-based  data  elements 

Employ  the  Comprehensive  Utilities  for  Data  Administration  (CUD A)  [20]  procedure  for 
reconciling  and  deconflicting  data  elements  and  data  models. 
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2.3.2  Data  Systems  Architecture 

RESOURCE  realization  as  the  central  objective  of  data  systems  architecture  within  DE-TF.  Systems 
architecture: 

•  defines  the  connection,  location,  and  identification  of  key  nodes,  networks,  and  DBMS  platforms 
and  specifies  the  required  system  and  component  performance  parameters,  and 

•  is  constructed  to  satisfy  the  operational  architecture  requirements  in  via  products  and  standards 
defined  in  DATA  Products. 

The  DATA  systems  architecture  addresses  system  implementation  requirements  at  two  levels: 

•  the  DATA  development  processes  for  creating,  registering,  maintaining,  interchanging,  and  releasing 
of  data  prior  to  simulation  execution,  and 

•  the  DATA  employment  processes  for  runtime  selection  and  manipulation  of  data  for  employment  or 
transmission  during  simulation  execution. 

The  DATA  development  processes  will  be  defined  in  Section  2.4.3  below.  Discussion  of  the  data  employment 
processes  is  beyond  the  scope  of  DE-TF  version  0.2. 

DATA  systems  architecture  describes  how  multiple  data  systems  within  a  subject  area  link  and 
interoperate.  While  external  specifications  are  preferred,  internal  constmction  or  operations  of  specific 
systems  may  be  described  where  the  internal  details  affect  interoperability  and  reuse.  In  particular  data 
systems  architecture: 

•  describes  the  components  and  structure  of  the  physical  process  which 
automate  or  enable  data  operations 

•  identifies  system  interfaces  and  defines  the  connectivity  between  systems, 

•  defines  system  constraints  and  bounds  of  system  performance  behavior, 

•  describes  technology  dependence  is  specific  systems  implementations,  and 

•  shows  systems  interconnectivity  from  consumer  through  the  repository  to  the  producer  (and 
authoritative  data  source)  via  the  quality  examiner,  security  officer,  and  requirements  manager. 

In  DE-TF  version  0.2,  the  data  systems  architecture  specifies  a  minimal  information  systems 
infrastructure  which  is  necessary  (but  not  sufficient)  for  data  realizations,  including 

•  the  Modeling  and  Simulation  Resource  Repository  (MSRR)  [1,3] 
for  consistent  physical  access  and  network  connectivity, 

•  a  families  of  DATA  interfaces,  and 

•  DISA  Shared  Data  Environment  (SHADE)  [22]  compatibility. 

The  MSRR  is  a  collection  of  M&S  registered  resources  and  RESOURCE  references,  logically  organized  by 
information  categories,  and  physically  implemented  using  a  distributed  system  of  resource  servers  connected 
through  the  World  Wide  Web  (WWW).  The  MSRR  provides  an  additional  layer  of  services  above  the 
WWW  that  includes  registration  of  resources,  users,  and  nodes;  description  and  quality  tagging  of  resources; 
security  and  releasability;  and  specialized  search  capabilities.  MSRR  provides  a  distributed  repository  for 
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approved  M&S  resources.  The  primary  objectives  of  the  MSRR  are  to  provide  members  of  the  M&S 
community  with  a  facility  to  electronically: 

•  Register  users,  nodes,  and  resources  with  the  MSRR  Registrar. 

•  Store  location  and  descriptive  information  about  M&S  RESOURCES. 

•  Protect  sensitive  but  unclassified  DATA. 

•  Store  selected  M&S  resources. 

•  Search  for  resources  via  categories  using  search  engines  and  database 
queries  on  the  master  registration  database. 

•  Access  authorized  descriptive  information  about  M&S  RESOURCES. 

•  Navigate  among  the  MSRR  nodes  and  review  resources  on  those  nodes  while 
retaining  an  MSRR  identity. 

•  Access  authorized  M&S  RESOURCES  stored  on  the  MSRR  or  on  nodes 
external  to  the  MSRR. 

•  Request  M&S  resources  from  resource  providers. 

Minimum  Requirement: 

DATA  systems  implementations  which  support  a  data  development  processes  shall  be  MSRR 
compliant. 

The  conversion  and  integration  of  data  requires  formal  format  standards  and  interfaces  definitions. 
The  DATA  system  architecture  defines  a  hierarchical  family  of  Data  Interchange  Format  (DIF)  definitions, 
interfaces,  tools,  and  utilities  including 

•  low  level,  file  format  or  DBMS  schema  interface  definitions  in  the  form  of  Interface 
Description  Language  (IDL)  [23],  Structured  Query  Language  (SQL)  [24], 
and/or  Backus  Naur  Form  (BNF)  [25], 

•  intermediate  level,  simulation  developer  Application  Programming  Interfaces  (API’s)  in  the 
form  of  Common  Object  Services  Specifications  (COSS)  [26] 

and/or  native  programming  language  calls,  and 

•  high  level,  simulation  end-user  Graphical  User  Interface  (GUI)  capability  in  the  form  of 
Common  Object  Facilities  [27]  and/or  native  windowing  schema’s. 

Minimum  Requirement: : 

DATA  systems  implementations  which  support  a  data  development  processes  shall  provide  a 
low  level  format  or  schema  interface  definition  using  at  least  one  of  the  following  forms: 
OMG  CORBA  IDL,  ANSFISO  SQL,  or  BNF. 

Preferred  Practice:  data  systems  implementations  which  support  a  data  development  process  should: 

provide  an  intermediate,  simulation  developer  API,  either  as  an  OMG  COSS  or  as  a  set  of 
native  high-level  programming  language  calls,  and 
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provide  high  level,  simulation  end-user  Graphical  User  Interface  (GUI)  capahility  in  the 
form  of  an  OMG  Common  Object  Facilities  or  a  native  windowing  schema. 

The  DISA  Shared  Data  Environment  (SHADE)  is  an  emerging  DoD  systems  architecture  standard  for 
data.  M&S  Data  Standard  Architecture  compatibility  and  interoperability  with  the  SHADE  beyond  the 
scope  of  DE-TE  version  0.2 

2.3.3  Data  Processes 

DE-TE  DATA  process  are  decomposed  into  two  primary  activities  —  those  to  develop  required  data  prior 
to  simulation  execution  and  those  to  actually  employ  data  during  simulation  execution: 

DATA  Development  Processes 

Descriptions  of  the  tasks,  operational  elements,  and  information  flows  required  for  creating, 
registering,  maintaining,  interchanging,  and  releasing  M&S  data  prior  to  simulation  execution. 

DATA  Employment  Processes 

Descriptions  of  the  tasks,  operational  elements,  and  information  flows  required  for  runtime 
selection  and  manipulation  of  M&S  data  for  employment  or  transmission 
during  simulation. 

This  section  specifies  the  DE-TE  data  development  processes.  Discussion  of  the  data  employment  processes 
is  beyond  the  scope  of  version  0.2  of  the  M&S  Data  Engineering  Technical  Eramework  provided  here. 

REPRESENTATION  implementation  and  data  development  are  concurrent,  spiral  development  activities  [28, 

29]  which  execute  iteratively  until  the  simulation  life-cycle  is  complete.  To  meet  these  requirements,  the 
DATA  development  processes  defines  two  distinct  (but  compatible)  views  into  the  underlying  data  life-cycle: 

•  the  closed-loop,  repository-centric  DATA  ENGINEERING  PROCESS  (Eigure  4) 

•  the  developer-centric  DATA  PRODUCTION  SEQUENCE  (Eigure  5)  and 

within  the  overall  simulation  development  and  employment  life-cycle.  The  central  objective  of  the  data 
development  processes  are  RESOURCE  implementation  repeatability.  Within  this  objective: 

.  The  DATA  ENGINEERING  PROCESS  focuses  on  an  iterative,  spiral  development  life-cycle 
for  enterprise  use  and  re-use  of  RESOURCES. 

.  The  DATA  PRODUCTION  SEQUENCE  focuses  on  a  once-through  waterfall  development  process  for  delivering  a 
specific  version  of  a  RESOURCE  by  a  particular  developer  within  the  larger 
DATA  Engineering  Process  spiral. 

2.4.3.1  Operational  Elements 

There  are  five  primary  operational  elements  or  functional  roles  performed  by  simulation  developers, 
end-users,  and  problem  domain  experts  shown  as  blocks  within  the  DATA  ENGINEERING  PROCESS  diagram 
depicted  in  Eigure  4: 


The  combination  of  person  and  organization  which  executes  the  role  of  resource  employment,  person, 
ORGANIZATION,  uud  ROLE  urc  dcfincd  in  [5,  29]. 
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The  combination  of  a  person,  organization,  and  role  which  constitute  the  actor  which  has  been 
assigned  a.)  the  command  responsibility  for  specific  content,  structure,  quality,  process,  or 
ownership  of  a  resource  and/or  b.)  the  management  authority  over  the  resources  required  to 
execute  command  responsibilities. 

The  combination  of  person,  organization,  and  role  which  constitute  the  actor  who,  because  of  either 
mission  or  subject  matter  expertise,  actually  creates,  manufactures, 
or  constructs  specific  resources. 


The  combination  of  person  and  organization  which  executes  the  role  of  resource  repository 
management. 


The  combination  of  a  person,  organization,  and  role  which  constitute  the  actor  that  actually  inspects, 
tests,  and  evaluates  specific  representation  content,  structure,  or  process  for  the  purpose  of 
verification,  validation,  and  certification  or  accreditation. 


2A.3.2  Information  Exchange  Requirements 

There  are  seven  primary  information  exchange  requirements  (or  interactions)  between  the  five 
operational  elements  (or  functional  roles)  shown  as  arrows  within  the  data  Engineering  Process  diagram 
shown  in  Figure  4: 

SPECIFY 

The  explicit  description  of  requirements  for  a  resource,  specify  provides  the  black-box  definition  of 
external  characteristics,  performance,  capabilities,  and  interfaces  required  of  a  resource  in  the 
form  of  CMMS  and  CMUS  representations  and,  for  data  resources  data  element  dictionaries  and 
(IDEFIX)  DATA  models  defining  the  logical  content  and  physical  constraints.  The  consumer  has  the 
lead  ROLE  to  propose  and  deliver  resource  specifications.  The  sponsor  has  the  response  role  to 
identify,  review,  and  concur  with  resource  specifications. 

ENDORSE 

The  formal  delegation  of  sponsor  authority  to  implement  an  approved  resource  by  expending 
RESOURCES  ALLOCATED  for  that  purposc.  Thc  SPONSOR  has  the  lead  role  to  propose  and  deliver  an 
ENDORSEMENT.  Thc  PRODUCER  hus  thc  rcsponsc  ROLE  to  identify,  review,  and  concur  with  an  endorsement. 

REGISTER 

The  formal  delivery  of  a  resource  for  actual  inclusion  in  a  repository,  especially  MSRR,  including 
source,  format,  and  content  checking  with  deficiency  correction  as  appropriate.  The  producer  has 
the  lead  role  to  propose  and  deliver  a  registration  subject  to  sponsor  approval.  The  administrator  has 
the  response  role  to  identify,  review,  and  concur  with  a  registration  subject  to  sponsor  allocation. 

RELEASE 

The  formal  permission  to  delivery  a  resource  for  consumer  activities,  especially  via  MSRR, 
including  the  provision  of  security  services,  access  control,  user  identification  for  use  and 
examination  of  the  resource.  The  administrator  has  the  lead  role  to  enforce  release  policy  subject  to 
sponsor  approval  and  the  response  role  to  deliver  released  resources  subject  to  sponsor  allocation. 

The  CONSUMER  has  the  lead  role  to  propose  and  justify  resource  release  and  the  response  role  to 
receive  released  resources. 
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REQUEST 

The  identification  of  the  need  for  a  formal  resoorce  examination  .  The  consumer  has  the  lead  role  to 
identify  the  resource  and  to  propose  the  examination.  The  examiner  has  the  response  role  to  review 
and  concur  with  the  proposed  resource  examination 

subject  to  SPONSOR  AUTHORIZATION. 

AUTHORIZE 

The  combination  of  approval  and  allocation  which  constitute  formal  sanction  of  the  requirement  to 
EXAMINE  a  resource,  of  the  designation  of  a  resource  as  authoritative,  or  of  the  permission  to  release  a 
RESOURCE  .  .  The  SPONSOR  haS  the  lead  role  provide  authorization.  The  consumer,  producer,  administrator, 
and  EXAMINER  have  the  response  role  to  review  and  concur  with  proposed  authorizations. 

SUBMIT 

The  formal  delivery  of  a  resource  for  examination  .  The  producer  has  the  lead  role  to  assemble, 
format,  package,  and  deliver  the  resource  and  supporting  meta-DATA  for  use  by  the  examiner.  The 
EXAMINER  and  CONSUMER  hus  thc  rcspousc  role  to  identify,  review,  and  concur  with  the  resource 

SUBMISSION  subject  to  SPONSOR  AUTHORIZATION. 


2A.3.3  Activities 

Within  the  five  primary  operational  elements  or  functional  roles  performed  hy  simulation  developers, 
end-users,  and  problem  domain  experts,  there  are  a  number  of  activities  conducted  primarily  or  exclusively 
by  that  functional  role.  These  activities  are  shown  as  a  list  of  actions  within  the  operational  element  blocks 
within  the  data  Engineering  Process  diagram  shown  in  Figure  4: 

The  CONSUMER  ROLE  cxecutcs  these  four  data  Engineering  Process  activities: 

LOCATE 

The  use  of  on-line  browsing  tools,  automated  searches,  and  retrieval  queries  to  identify  resources 
of  interest,  common  semantics  and  syntax  is  applied  to  construct  searches 
and  to  recognize  resources. 

ACCESS 

The  use  of  resource  retrieval  services  to  obtain  located  resources.  For  data  resources,  data  interchange 
FORMATS  are  employed  via  application  programming  interfaces  and/or  graphical  user  interface 
(GUI)  services  to  gather,  format,  package,  and  deliver  Data  to  the  consumer. 

Evaluate 

CONSUMER  actions  to  determine  that  a  particular  resource  does  or  does  not 
satisfies  specific  consumer  requirements. 

EMPLOY 

CONSUMER  usage  of  a  particular  resource  to  satisfy  specific  end-use  requirements. 

The  SPONSOR  ROLE  exccutcs  these  two  data  Engineering  Process  activities: 

APPROVE 

The  command  decision  and  official  sanction  with  respect  to  a  resource  that  a  requirement  is 
justified,  a  register  or  release  is  appropriate,  an  examination  is  satisfactory,  or  a  data  source  is 

AUTHORITATIVE. 
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ALLOCATE 

The  programmatic  authority  and  official  sanction  to  expend  resources  to  fulfill  a  requirement,  to 
perform  a  register  or  conduct  a  release,  or  to  conduct  an  examination  . 

The  PRODUCER  ROLE  cxccutes  these  four  data  engineering  process  activities: 

DESIGN 

The  deliberate  purposive  planning  by  which  the  nature  and  arrangement  of  elements  which 
constitute  a  resource  are  described  and  a  scheme  for  implementing  these  elements  is  devised. 

DESIGN  provides  the  clear-box  definition  of  the  internal  elements  of  a  resource. 

Create 

The  actual  construction  of  a  resource. 

Convert 

Transformation  of  a  registered  resource  from  its  native  form  into  data  in  a  standard  form  with 
COMMON  SEMANTIC  AND  SYNTACTIC  clcments  for  archivc  and  interchange. 

Integrate 

The  act  of  combining,  normalizing,  mapping,  matching,  indexing,  and  in  general  migrating 
REGISTERED  DATA  in  Standard  form  to  a  higher  level  of  syntatic  maturity  and  semantic  enforcement 
within  a  common  repository. 

The  ADMINISTRATOR  ROLE  cxccutcs  thcsc  fout  DATA  engineering  process  activities: 

CATALOG 

The  provision  of  a  complete  enumeration  of  registered  resouces  arranged  systematically  within  an 
appropriate  taxomony  which  provides  meta-DATA  and  descriptive  details  to  support  consumer  locate 
and  ADMINISTRATOR  STORE,  CONFIGURE,  and  PURGE  activitics. 

STORE 

The  provision  of  resource  persistence  and  recovery.  For  data  resources,  the  provision  of  persistent 
file  server  and  DBMS  RESOURCES. 

CONFIGURE 

The  provision  of  resource  configuration  management,  version  control,  and  change  traceability. 

PURGE 

The  removal  and  retirement  of  (previously)  persistence  resources. 

2.3.3.4  Data  Production  Sequence 

While  the  data  engineering  process  provides  a  view  of  the  overall  use  and  reuse  of  data  via  a  common 
(likely  distributed)  repository,  the  DATA  PRODUCTION  SEQUENCE  (Figure  5)  focuses  on  the  development  of  a  specific 
set  of  DATA  instances: 

•  hy  a  PRODUCER, 

•  to  complete  an  explicit  REPRESENTATION, 

•  to  meet  an  endorsed  set  of  requirements, 

•  as  specified  hy  a  CONSUMER. 
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The  DATA  PRODUCTION  SEQUENCE  Is  d  refinement  and  elucidation  of  the  design  and  create  activities.  Within  this 
sequence,  the  producer  has  the  lead  role  to  propose  and  conduct  the  activities  and  initiate  the  information 
exchanges  required  to  ultimately  construct  the  required  data.  The  consumer,  administrator,  examiner  and  sponsor 
have  the  response  role  to  identify  and  provide  the  authorized  input  resources  for  the  cREATE-related  activities  and 
to  review  and  concur  with  DESIGN-  related  activities. 

This  sequence  is  composed  of  four  primary  activities  conducted  hy  the  producer  operational  element, 
with  appropriate  assistance  from  the  other  operational  elements.  These  activities  are  shown  as  a  sequence 
of  boxes  within  the  data  Engineering  Process  diagram  shown  in  Figure  5: 


DEVELOP  FOCUSED  CONTEXT 

SPECIFY  concrete  operational  conditions  using  CMMS  representations,  establish  end-user  priorities 
and  constraints  using  CMUS  representations,  and  establish  output  resource  requirements  using 

ENDORSED  SPECIFICATIONS. 


Establish  the  preliminary  design  by  conducting  coordinated  resource  repository  searches  and  site- 
visits  to  subject  matter  experts  to  locate,  evaluate,  and  ultimately  obtain  release  of  required  input 

RESOURCES  within  the  focused  context. 

FORMALIZE  INPUT  RESOURCES 

Complete  the  detailed  design  the  required  resource  by  organizing  the  input  resources,  using  common 
SEMANTICS  AND  SYNTAX  uud  DATA  INTERCHANGE  FORMATS,  where  appropriate,  iuto  Standard  forms  for 

PRODUCTION  use. 


CONSTRUCT  RESOURCE 

EMPLOY  the  FORMALIZED  INPUT  RESOURCES  tO  PRODUCE  the  Tequired  OUtpUt  RESOURCES. 

The  arrows  between  the  activity  blocks  in  Figure  5  represent  information  exchange  requirements,  likely  via 
MSRR,  as  define  in  Section  2.4.3.2  above. 

Minimum  Requirement: 


DATA  CREATED,  REGISTERED,  maintained  and  RELEASED  under  the  M&S  Data  Fngineering  Technical 
Framework  shall  be  produced  in  accordance  with  the  DATA  PRODUCTION  SEQUENCE. 

DATA  CREATED  and  EMPLOYED  under  the  M&S  Data  Fngineering  Technical  Framework  shall  be 

SPONSORED,  PRODUCED,  EXAMINED,  ADMINISTERED,  and  CONSUMED  in  accordance  with  the  DATA  ENGINEERING 
PROCESS. 


2.4.4  Data  Products  Technical  Architecture 

The  central  data  products  objective  is  to  enable  the  composable  solutions  strategy  by  defining  reusable, 
shrink-wrapped  RESOURCES.  For  DATA  RESOURCES,  DF-TF  defines  five  key  DATA  products 

•  authoritative  data  sources 

•  authorized  data  consumers 

•  data  interchange  formats 

•  data  quality  products  and  procedures 
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•  data  security  products  and  procedures 

2.3.4.1  Authoritative  Data  Sources 

This  section  describes  the  representation  requirements  which  ensure  that  the  accuracy  and  authenticity  of 
any  particular  data  is  specified  in  sufficient  detail  for  a  simulation  developer  or  end-user  to  recognize  the 
suitability  of  that  data  for  that  simulation  developer’s  or  end-user’s  specific  requirements. 

PRODUCTION  PEDIGREE 

The  comprehensive  audit  trail  which  describes  the  specific  methods  and  procedures  actually 
employed  by  the  producer  to  create,  derive,  and  construct  a  particular  data  instance  for  specified 
end-use.  This  pedigree  provides  data  source  traceability  for  constituent  Data  instances  which  were 
incorporated  into  or  employed  to  produce  the  particular  data  instance  in  question. 

DATA  SOURCE  (ds) 

The  combination  of  sponsor,  producer,  data,  and  production  pedigree  which  provide  a  Data  instance. 

The  PRODUCER  creates  the  actual  data  instance  by  direction  of  the  sponsor  and  records  these  activities 
in  the  pedigree.  This  definition  of  data  source  is  a  compatible  extension  of  the  definitions  in  [3-4]. 

W&C  PEDIGREE 

The  comprehensive  audit  trail  which  records  the  formal  verification,  validation,  and  accreditation 
activities  actually  performed  on  a  particular  data  source  by  the  examiner.  This  pedigree  also  provides 
traceability  for  input  data  instances  or  models  which  a.)  were  employed  to  produce  the  actual  data 
instances  provided  in  the  data  source  in  question  but  which  b.)  were  not  delivered  along  with  these 
actual  DATA  instances  being  examined. 

AUTHORITATIVE  DATA  SOURCE  (aDS) 

The  combination  of  sponsor,  examiner,  data  source,  and  w&c  pedigree  which  provide  one  or  more  data 
instances  have  verified,  validated,  certified/accredited  in  accordance  with  appropriate  DoD  or 
Service  w&c  procedure.  The  examiner  analyzes  that  actual  data  instance  provide  by  the  data  source 
under  direction  of  the  sponsor  and  records  these  activities  in  the  W&C  pedigree.  This  definition  of 
AUTHORITATIVE  DATA  source(ads)  is  a  Compatible  extension  of  the  definitions  in  [3-4]. 


Minimum  Requirement: 

All  DATA  shall  be  REGISTERED  by  an  AUTHORITATIVE  DATA  SOURCE  which  have  been  APPROVED  by  an 

appropriate  Joint,  Service,  or  Agency  SPONSOR. 

For  example,  in  the  military  operation  mission  space,  the  actual  warfighter  in  hostile,  live-fire  combat 
operations  is  the  original  DATA  SOURCE.  However,  simulations  based  on  such  a  data  source  are  of  minimal  value 
in  the  absence  of  verification,  validation,  and  eventually  accreditation.  Doctrine  is  a  disciplined  attempt  to 
learn  for  these  warfighter  experiences.  Just  so,  the  requirement  that  all  data  be  registered  by  an  authoritative 
DATA  SOURCE  Is  an  attcmpt  to  introduce  that  same  discipline  into  simulations.  This  ads  framework  provides  the 
rigorous  data  source  traceability  and  configuration  management  which  is  required  to  support  w&c  by 
competent  authority. 

Preferred  Practice: 

To  support  concurrent  work-in-progress  by  data  source,  w&c  examiner,  and  simulation 

developers,  DATA  from  a  sponsor  approved  DATA  SOURCE  may  bC  REGISTERED,  CONVERTED,  and  INTEGRATED  ill 
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parallel  with  examiner  activities  to  provide  the  required  w&c  for  AUTHORITATIVE  DATA  SOURCE 

approval. 

2.3.4.1  Authorized  Data  Consumers 

This  section  describes  the  requirements  which  control  the  RELEASABILITY  of  any  particular  data  to  a  specific 
simulation  developer. 

CLEARANCE 

The  AUTHORIZATION  that  a  specific  consumer  is  legally  eligible  to  be  entrusted  with  classified, 
proprietary,  or  otherwise  sensitive  data  instance. 

ACCESS 

The  AUTHORIZATION  that  a  specific  combination  of  a  consumer  with  a  particular  clearance  under  the 
authority  of  an  identified  sponsor  has  an  appropriate  need-to-know  for  a  specific  classified, 
proprietary,  or  otherwise  sensitive  data  instance. 

SECURITY  PEDIGREE 

The  comprehensive  audit  trail  which  records  the  specific  methods  and  procedures  actually 
employed  by  the  consumer  under  authority  of  the  sponsor  to  ensure  that  any  specific  data  instance  has 
been  properly  protected 

DATA  CONSUMER  (dc) 

The  combination  of  sponsor,  consumer,  clearance,  access,  and  security  pedigree  which  requests 
permission  to  locate,  extract,  or  evaluate  a  specific  data  instance.  The  consumer  requests  and 
eventually  receives  the  actual  data  instance  by  direction  of  the  sponsor  and  records  these  activities 
in  the  security  pedigree. 

RELEASE  PEDIGREE 

he  comprehensive  audit  trail  which  records  the  specific  methods  and  procedures  actually 
employed  by  the  administrator  under  authority  of  the  authoritative  data  source  (ads)  to  release  any 
specific  DATA  instance  to  a  data  consumer. 


AUTHORIZED  DaTA  CONSUMER 

The  combination  of  data  consumer,  authoritative  data  source  and  release  pedigree  certifies  the  release  of 
one  or  more  data  instances  from  the  authoritative  data  source  to  the  data  consumer.  The  administrator 
records  these  activities  in  the  release  pedigree.  This  definition  of  authorized  data  consumer  (adc)  is  a 
compatible  extension  of  the 
definitions  in  [3-4]. 
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Minimum  Requirement: 

Each  CONSUMER  shall  he  an  AUTHORIZED  DATA  CONSUMER.  DATA  shall  not  he  RELEASED  to  any  consumer  who  is 
not  an  authorized  data  consumer. 


2.3A.3  Data  Interchange  Formats 

[TBD] 

2.3AA  Data  Quality  Products  and  Procedures 

[TBD] 

2.3.4.5  Data  Security  Products  and  Procedures 

[TBD] 


2.3.5  Functionai  Data  Administration 


[TBD] 

3.  Detaiied  Definition  of  M&S  DE-TF  Products  and  Processes 

[TBD] 
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Figure  2-1.  Federation  Development  and  Execution  Process  Model 


JWARS/JSIMS  Mission  Space 


Phases  of  military  operations 


(for  war  and  MOOTW  scenarios) 


Figure  3 
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Primary  Drivers  (Deliver,  Propose,  Lead) 
Secondary  Feedback  (Identify,  Review,  Concur) 


Figure  4 
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6.  Tables 


Table  1 


UJTL  LEVEL  OF 

LIVE 

VIRTUAL 

CONSTRUCTIVE 

WAR 

SIMULATION 

SIMULATION 

SIMULATION 

STRATEGIC 

NATIONAL 

TASK 

synthetic 

synthetic 

synthetic 

PHYSICAL 

real 

synthetic 

synthetic 

WARFIGHTER 

real 

real 

synthetic 

STRATEGIC 

THEATER 

TASK 

synthetic 

synthetic 

synthetic 

PHYSICAL 

real 

synthetic 

synthetic 

WARFIGHTER 

real 

real 

synthetic 

OPERATIONAL 

TASK 

synthetic 

synthetic 

synthetic 

PHYSICAL 

real 

synthetic 

synthetic 

WARFIGHTER 

real 

real 

synthetic 

Tactical 

TASK 

synthetic 

synthetic 

synthetic 

PHYSICAL 

real 

synthetic 

synthetic 

WARFIGHTER 

real 

real 

synthetic 

7.  Specifications  Compendium 
7.1.  Minimum  Requirements: 

1  DATA  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Framework  shall  he  traceable  to  an  appropriate  REPRESENTATION  of  the 
corresponding  problem  domain  ABSTRACTION  registered  in  CMMS. 

2  DATA  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Framework  shall  be  traceable  to  an  appropriate  REPRESENTATION  of  the 
implementation  domain  ABSTRACTION  registered  in  a  CMUS. 

3  DATA  created,  registered,  maintained  and  released  under  the  M&S  Data  Engineering 
Technical  Framework  shall  be  described  using  COMMON  SEMANTICS  AND  SYNTAX,  including  but  not 
limited  to: 
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3.1  A  taxonomy  which  identifies  the  key  organizing  principles  and  primary  describing 
dimensions  of  the  REPRESENTATION  which  the  data  completes.  This  taxonomy  shall  include 
hut  is  not  limited  to  the  organizing  principles  defined  in  Table  2. 

3.2  DATA  element  dictionary  which  complies  with  the  DoD  Data  Dictionary  System  [5] 
structure  and  content  specifications. 

3.3  A  DATA  model  which  defines  the  relationships  between  the  elements  in  the  data 
dictionary  within  the  taxonomy  provided  and  which  complies  with  the  DoD  Data 
Model  [17]  structure  and  content  specifics. 

4  DATA  systems  implementations  which  support  a  data  development  process  shall  be  MSRR 
compliant. 

5  DATA  systems  implementations  which  support  a  data  development  process  shall  provide  a  low 
level  format  or  schema  interface  definition  using  at  least  one  of  the  following  forms:  OMG 
CORBA  IDL,  ANSI/ISO  SQL,  or  BNF. 

6  DATA  CREATED,  REGISTERED,  maintained  and  RELEASED  under  the  M&S  Data  Engineering  Technical 
Framework  shall  be  produced  in  accordance  with  the  DATA  PRODUCTION  SEQUENCE. 

7  DATA  CREATED  and  EMPLOYED  under  the  M&S  Data  Engineering  Technical  Framework  shall  be 

SPONSORED,  PRODUCED,  EXAMINED,  ADMINISTERED,  and  CONSUMED  in  accordance  with  the  DATA  ENGINEERING 
PROCESS. 

8  All  DATA  shall  be  REGISTERED  by  an  AUTHORITATIVE  DATA  SOURCE  which  have  been  APPROVED  by  an 

appropriate  Joint,  Service,  or  Agency  SPONSOR. . 

9  Each  CONSUMER  shall  be  an  AUTHORIZED  DATA  CONSUMER.  DATA  shall  not  be  RELEASED  to  any  consumer  who  is 
not  an  authorized  data  consumer. 

7.2  Preferred  Practices 

1  The  required  CSS  data  model  and  associated  data  elements  should  be  constructed  in 
accordance  with  DoD  5000.59-M-l  [18]. 

2  DATA  systems  architecture  implementations  which  support  a  data  development  process 
should: 

2. 1  provide  an  intermediate,  simulation  developer  API,  either  as  an  OMG  GOSS  or  as  a 
set  of  native  high-level  programming  language  calls,  and 

2.2  provide  high  level,  simulation  end-user  Graphical  User  Interface  (GUI)  capability  in 
the  form  of  an  OMG  Common  Object  Facilities  or  a  native  windowing  schema. 

3  To  support  concurrent  work-in-progress  by  data  source,  w&c  examiner,  and  simulation 

developers,  DATA  from  a  SPONSOR  APPROVED  DATA  SOURCE  mSy  bC  REGISTERED,  CONVERTED,  and  INTEGRATED  ill 

parallel  with  examiner  activities  to  provide  the  required  w&c  for  AUTHORITATIVE  DATA  SOURCE 

approval. 
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7.3  Technology  Extensions 

1  Employ  the  Data  Analysis  and  Reconciliation  Tool  (DART)  [19]  to  define  entity-based  data 
elements. 

2  Employ  the  CMMS  Verb  Dictionary  [20]  to  define  action-based  data  elements 

3  Employ  the  Comprehensive  Utilities  for  Data  Administration  (CUDA)  [21]  procedure  for 
reconciling  and  deconflicting  data  elements  and  data  models. 

Enclosures  [TBD] 

Annexes  [TBD] 
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